I played around with creating a very rough draft class diagram (top) as well as updating the domain model a little. I want some feedback before I commit to anything official. I'm still struggling with what Wolff put in feedback about abstracting the puzzle object and how to represent puzzles in progress. Currently, I'm thinking that puzzle progress will be stored per user as a Level type object? Essentially storing their board state? It doesn't feel quite right. Other than that, actually representing the board is kinda being weird to me. I think its helpful conceptually to think about the Board being made up of several cells, but on a practical level, its much easier to have the Board be a simple 2D array, with the cells just being X, Y pairs in that array, which is what I have tried to model in the class diagram.
Implementation focused time! I tried my best to follow along with the Jackson packages for reading in JSON files, since it seems someone (probably Eric) already set that up within our packages. To that end, there is a new Puzzle Class that reads in the data from the PuzzleDTO. However, for ease, I am still using the CellDTO to represent an actual Cell object. They are functionally the same, so it may be worth just changing the name of CellDTO to Cell. (and thus retiring the Cell class that I made in testing)
22:28
On the Cell Class, I added a method that cycles the type. The type is a simple String that has 3 states (from the user perspective): EMPTY, STAR and MARKER. The changeType() method takes a boolean that is standing in for a left vs right click action. On left click, it cycles to the next type. On right click, it clears, setting the cell to empty.
On the Puzzle Class, it loads in all the data from a PuzzleDTO (regions, gridSize, etc) allowing for easy conversion from JSON to a usable object. It also has a 2D Cell array board, separate from regions. This is to easily check spatially related cells, such as rows, columns or adjacent. Speaking of which, there is now a checkBoard method that should likely be called whenever a change is made to the board. It checks the rows and columns, seeing if there are multiple stars in that row or not. It takes a boolean input visible that tells the program whether it should auto-generate markers (thus they are visible on the board). It also checks adjacent spaces to any cells with stars. It automatically detects whether a placement is valid, by setting stars that are too many to "INVALID" type. Auto-generated markers are set to type "VMARKER", so that they can be differentiated from player-placed markers. Auto-generated markers are automatically removed when calling checkBoard(false). I'm realizing that these extra types may not work with the cycling method of cell, so I may have to adjust that at a later time.
22:37
There is a domainTest class that demos a lot of this, and included in Puzzle is a helpful printBoard method that has a text representation of the board with each cell's type
Reworked pretty much all of the code I wrote on Wednesday. Same basic ideas apply, but my boardCheck method now only checks single row and column of cells with stars in them rather than the whole board. Also implemented the region check and tacked it onto the end of the boardCheck
@Eric Golde Moving back into this chat. Have you made it so onClick calls the changeType method? That was my initial intention with that method and without it, I'm not sure what the domainTest will do.
Brandon
@Eric Golde Moving back into this chat. Have you made it so onClick calls the changeType method? That was my initial intention with that method and without it, I'm not sure what the domainTest will do.
Yes, i just renamed the method, and inverted your if statement
19:49
so with splitting everything, I will split the drawing code out of the Cell, and out of the Puzzle class, into like PuzzleComponent and CellComponent classes. Then we can move them out of the UI class if needed
Oh sorry, this was confusing code on my part. It needs to call the PuzzleClass changeType, which is supposed to remotely call the Cell class changeType and do clearAdjacent if necessary.
Hey Eric, it looks like the Puzzle in DomainTest is loading in with a bunch of stars pre-placed. Is that an intended implementation thing? Like is it reading in the solution?
@Eric Golde I seem to have found rather an annoying discrepancy that may need to be addressed. All of your board referencing is done [col][row] and all of my board referencing is done [row][col]. I figured out that is why my test is not behaving as expected.
Okay getting all those flipped around on my end seems to have fixed any remaining errors. I'm going to push a decent number of changes now, so you may want to pull again @Eric Golde
20:28
I also made it so onClick calls the Puzzle changeType (now onClick), instead of the Cell one
20:28
The Cell on is back to being changeType
Brandon
@Eric Golde I seem to have found rather an annoying discrepancy that may need to be addressed. All of your board referencing is done [col][row] and all of my board referencing is done [row][col]. I figured out that is why my test is not behaving as expected.
Okay getting all those flipped around on my end seems to have fixed any remaining errors. I'm going to push a decent number of changes now, so you may want to pull again @Eric Golde
It looks good, not sure if its really divided cleanly into packages at this point. It still kinda feels like they are all floating in nebulous space except for the few that are connected
That would be right. There is no package level organization at the moment. Just shows our classes, and where they inherit from.
I highlighted some classes that come from each.
Key based off of food colors
Outlined by Red () = UI
Outlined by Yellow ( ) = Server
Outlined by Green ( ) = Model
Ok, so currently this is what I got. I don't necessarily know how granular he wants it. I broke it up as such.
UI Package: contains screens, popups, and most general webb components (swing-based components tailored to our game)
Server: Has the REST controllers, a repository for managing/reading/writing database stuff, and the player manager which is our authentication sub package.
Domain: Is broken up into stuff that deals with the players and the puzzle.
A couple of things that I realized is that the leaderboard isn't necessarily here. I would assume that would be on the server, but probably should be modelled in a way?
17:33
Dashed lines are depends on, and the bold strong lines are just a messaging scheme
Perfect, I've started chipping away at the UI class diagrams (see ui-design channel). I think if we do that, get all the diagrams collated, and make sure mine and Eric's combined branch gets pushed to main, we should be pretty much ready to turn in.
looks good!
I may advoid merging it to main atm. Is there any way we can tag iteration2 as another branch?
I mean we can merge it, its just not fully tested
That is a little out of my sphere of knowledge. I was hoping someone else could handle the tagging. There is probably a way to tag it, I have to imagine.
looks good!
I may advoid merging it to main atm. Is there any way we can tag iteration2 as another branch?
I mean we can merge it, its just not fully tested
1
). For all, feedback is welcomed when you get the chance.
1
1
) = UI
Outlined by Yellow (
) = Server
Outlined by Green (
) = Model
